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SUMMARY 

This  paper  addresses  the  problem  of  developing  a 
storage  and  test  policy  which  may  be  applied  to  equip¬ 
ment  placed  in  long-term  storage  prior  to  utilization. 

A  closed-form  analytic  solution  is  developed  to  aid  in 
evaluating  the  characteristics  of  a  given  policy  in 
terms  of  test  efficiency,  on  time  delivery,  and  subse¬ 
quent  reliable  operation  of  the  equipment  in  its  inten¬ 
ded  application.  The  analysis  model  is,  to  the  authors 
knowledge,  new  and  hence  is  described  in  detail;  a  com¬ 
puter  program  based  on  the  model  is  outlined  and  a  flow 
diagram  of  its  logic  included.  Problems  associated 
with  estimating  valid  input  data  are  treated.  An  exam¬ 
ple  of  the  application  of  the  analysis  to  spacecraft  is 
presented  to  fully  illustrate  the  approach.  Finally, 
the  paper  closes  with  a  discussion  of  some  of  the  many 
situations  in  which  such  a  tool  could  be  employed  in  a 
variety  of  Industrial,  research,  and  sports  contexts. 

1.  INTRODUCTION 

The  advent  of  replenishable  multi-satellite  sys¬ 
tems  in  recent  years  (TIROS  is  a  good  example)  has 
created  a  requirement  for  the  long-term  storage  of 
spacecraft.  Such  a  requirement  led  to  the  development 
of  the  analysis  tool  described  in  this  paper.  The 
problems  will  vary  from  case  to  case  depending  largely 
on  two  types  of  factors:  (i)  the  engineering  charac¬ 
teristics  of  the  hardware  Involved  (e.g.,  susceptibil¬ 
ity  to  corrosion,  sensitivity  to  a  l.Og  field,  poten¬ 
tial  temperature  effects,  etc.);  and  (ii)  the  charac¬ 
teristics  of  the  mission  which  the  hardware  is  called 
upon  to  perform  (e.g.,  is  the  system  repairable  or  not 
after  it  is  placed  in  operation?,  is  the  demand  for 
the  equipment  random  or  based  upon  a  predetermined 
schedule?,  how  soon  after  usage  demand  must  the  hard¬ 
ware  be  put  into  service?,  etc.).  This  paper  deals 
largely  with  the  second  class  of  decisions  which  must 
be  approached  in  many  cases  on  a  statistical  basis ^ 

The  first  class  of  problems  is  more  deterministic  in 
nature,  and  generally  fairly  well  understood  in  the 
industry:  storage  in  dry  nitrogen  with  periodic  rota¬ 
tion  of  l.Og  sensitive  components  are  among  widely 
followed  policies. 

While  the  illustrations  included  in  the  paper  are 
written  largely  in  the  context  of  a  stored  spacecraft 
subject  to  an  unscheduled  launch  call,  the  same  problem 
occurs  for  other  classes  of  equipment;  notably  weapon 
systems  held  in  readiness  for  use  only  in  the  event  of 
an  emergency,  electronic  parts  stored  prior  to  assembly, 
TV  sets  stored  in  a  warehouse  or  showroom,  and  used 
cars  on  the  comer  lot.  The  primary  concern  with  stor¬ 
ed  equipment  is  that  it  works  properly  when  it  is 
called  upon  to  be  usud.  This  motivation  usually  re¬ 
sults  in  some  testing  being  performed  on  the  equipment 
after  it  is  taken  out  of  storage  prior  to  its  actual 
use.  Problems  uncovered  during  the  post  call-up  tests 
are  repaired  prior  to  use  to  provide  maximum  confidence 
that  a  successful  mission  will  result.  Another  factor 
important  in  many  operational  contexts  is  a  requirement 
to  respond  very  rapidly  to  the  activation  call-up;  to 
compensate  for  reduced  testing  after  call-up,  periodic 
testing  during  the  storage  period  is  often  considered. 
This  paper  describes  a  dynamic  model  of  this  situation 
which  may  be  exercised  to  define  a  storage  and  test 


policy  consistent  with  the  dual  objectives  of  (i)  re¬ 
sponding  on  time  to  the  call-up,  and  (ii)  having  ade¬ 
quate  assurance  that  the  equipment  is  failure  free  at 
the  time  its  utilization  begins. 

2.  ANALYSIS  MODEL 
The  Storage  Sequence  of  Events 

The  general  sequence  of  events  occurring  in  a 
typical  storage  situation  is  illustrated  in  Figure  1. 
The  equipment  is  placed  into  storage;  at  that  time 
there  may  be  undetected  failures  present.  These 
failures  could  result  from  Inadequate  testing  or  the 
inability  of  the  test  equipment  to  detect  the  failure. 
Some  storage  time  occurs  and  depending  upon  the  indi¬ 
vidual  storage  policy  being  evaluated,  testing  may  be 
done  on  a  periodic  basis.  Failures  may  occur  during 
storage,  during  test  or  may  be  Induced  by  the  testing 
Itself.  The  test  will  detect  some  percentage  (typi¬ 
cally  not  all)  of  whatever  defects  are  present  (inclu¬ 
ding  previously  undetected  defects)  before  the  equip¬ 
ment  is  returned  to  storage.  Finally,  the  call  to  use 
the  stored  item  occurs,  a  final  test  may  or  may  not  be 
done  and  the  equipment  is  then  applied  to  its  end  use, 
hopefully  free  of  failures  (no  undetected  failures). 

The  model  described  herein  is  a  probabilistic 
analysis  of  the  various  events  which  take  place  in  the 
storage  sequence.  It  uses  an  analytic  of  closed-form 
approach  as  contrasted  with  a  Monte  Carlo  simulation 
approach;  consequently,  the  computer  run  time  required 
to  evaluate  an  individual  case  is  very  nominal..  The 
direct  thrust  of  the  model  output  focuses  on  (i)  the 
number  of  failures  which  may  be  detected  after  the 
call-up  decision  has  been  made  and  (ii)  the  consequent 
delay  induced  by  these  detected  failures  assuming  that 
usage  will  not  begin  until  all  anomalies  are  repaired 
and  retest  completed.  As  was  indicated  in  the  summary, 
however,  almost  any  type  of  ’information  describing  the 
effectiveness  of  a  storage  policy  may  be  determined. 
Through  a  suitable  structuring  of  multiple  cases,  one 
may  estimate  (i)  the  efficiency  of  a  test  (how  many 
failures  it  detects  versus  how  many  it  introduces) ; 

(ii)  the  number  of  defects  present  when  storage  begins; 
and  (iii)  the  number  of  defects  likely  to  remain  when 
the  equipment  is  put  into  service.  These  points  are 
further  illustrated  in  the  examples  discussed  in  Sec¬ 
tion  3  of  this  paper.  The  computer  program  which 
Implements  this  analysis  thus  represents  a  tool  which 
may  be  used  in  a  variety  of  ways  to  evaluate  many 
aspects  of  the  storage  problem.  As  with  any  tool,  the 
way  in  which  it  will  be  applied  depends  upon  the  job 
to  be  done. 

Computer  Program  Inputs  and  Outputs 

The  computer  program  requires  inputs  which  de¬ 
scribe  the  pertinent  characteristics  of  the  hardware 
and  of  the  storage  policy  being  contemplated  for  that 
hardware.  In  addition,  certain  input  variables  are 
defined  solely  in  the  Interests  of  computer  processing 
efficiency  and  output  format  standardization.  The 
direct  outputs  of  the  program  describe  the  ntomber  of 
failures  detected  after  the  use  decision,  and  the  days 
of  delay  induced  by  these  failures  before  the  equip¬ 
ment  is  available  for  actual  service.  As  discussed 
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earlier,  many  other  conclusions  may  be  drawn  based  upon 
the  joint  evaluation  of  several  structured  cases. 

The  basic  Inputs  and  outputs  are  listed  In  Table  1. 
The  launch  call  time  Is  treated  as  an  Input  variable; 
by  varying  launch  call  time,  a  given  test  schedule  can 
be  evaluated  against  a  range  of  contingencies.  Many  of 
the  Inputs  are  accumulated  Into  a  data  file  made  up  of 
data  which  remains  largely  Invariant  for  a  large  number 
of  cases.  These  Include  Che  characteristics  of  the 
hardware  Itself  for  each  Item:  Its  likelihood  of  fail¬ 
ure  In  various  tests;  its  storage  failure  race;  the 
likelihood  failures  will  be  detected  for  each  item  in 
various  tests;  the  probability  each  item  will  have  un¬ 
detected  failures  when  entering  storage;  and  the  repair 
time  in  days  should  an  item  fall.  Other  inputs  which 
vary  from  case  to  case  are  Input  directly  for  each  case. 


P(F=x) 


(Xt)V^ 


0,  1,  2, 


where, 

X  “  in-storage  failure  rate 
t  °  time  In  storage 
F  “  number  of  failures 


•  Number  of  failures  occurring  during  test  also  Is 
treated  with  Poisson  distribution;  also  number  of 
defects  present  prior  to  storage. 

•  An  item  is  spared  or  unspared;  for  items  which  are 
spared  it  is  assumed  Chat  a  spare  is  available  in 
the  event  of  test  failure. 


Table  1.  Analysis  Model  Inputs  and  Outputs 
INPUTS 

•  Call-up  time  and  call-up  test  type. 

•  Number  and  types  of  tests  scheduled  prior  to  call-up. 

•  Interval  between  tests. 

•  Storage  failure  rates  for  each  item  (or  subcategory 
of  equipment) . 

•  Probability  of  no  defects  present  when  put  into 
storage  for  each  item. 

•  Restoration  times  should  failure  occur  during  test¬ 
ing  for  each  item. 

•  For  each  type  of  test: 

-  Probability  of  no  additional  failures  during 
test  for  each  item, 

-  Probability  failure  present  before  test  will 
be  detected  during  test  for  each  item, 

-  Probability  new  failure  occurring  during  test 
will  be  detected  during  test  for  each  item. 

•  Compl'exity  factor  (a  measure  of  number  of  failures 
anticipated,  used  only  to  size  matrices  in  computer 
program) . 

•  Units  factor  (delay  measured  in  days  of  some  multi¬ 
ple  thereof). 

•  Efficiency  factor  (measure  of  non-additlvlty  of 
actual  delays,  amount  of  multiple  repairs  being 
simultaneously  performed). 

OUTPUTS 

•  Probability  distribution  of  number  of  detected  fail¬ 
ures  for  each  item  during  call-up  test  sequence. 

•  Probability  distribution  of  days  of  delay  due  to 
failures  detected  during  call-up  test  sequence. 

•  Average  days  of  delay  due  to  failures  detected  dur¬ 
ing  launch  call-up  test  sequence. 

Steps  in  Analysis 

The  analysis  of  the  storage  process  shown  in  Fig¬ 
ure  1  is  implemented  through  the  steps  described  in 
Figure  2.  These  steps  also  correlate  with  sections  of 
the  computer  program.  The  method  of  analysis  operates 
upon  probability  distributions  which  govern  the  various 
events.  Some  overall  assumptions  about  the  form  of 
these  distributions  built  into  the  analysis  include: 

•  Storage  failure  rates  are  constant  with  time;  hence, 
the  number  of  failures,  F,  occurring  in  storage 
follows  a  Poisson  distribution. 


Figure  2  is  a  simplified  flow  diagram  of  these  steps. 

A  careful  review  of  Table  2  and  Figure  2  should  result 
in  the  development  of  an  adequate  understanding  of  the 
analysis  so  that  the  reader  could  apply  the  methology 
with  his  own  computer  program.  The  method  is  further 
illustrated  by  the  examples  contained  in  Section  3. 
Another  approach  to  modeling  a  similar  situation  using 
Markov  chains  may  be  found  in  Reference  1. 

Table  2.  Steps  in  Analysis  and  Computer  Program 

1.  Input  complexity  factor,  units  factor,  efficiency 
factor,  E'. 

2.  Input  time  to  call-up  in  days,  type  of  call-up 
test. 

3.  Input  number  of  scheduled  tests  prior  to  call-up. 
A.  Dimension  matrices. 

5.  Input  test  type  for  each  scheduled  test. 

6.  Input  storage  time  between  each  scheduled  test. 

7.  Read  data  file. 

8.  N  “  Number  of  subsystems  or  items,  N1  =  Number  of 
tests  prior  to  use. 

9.  Start  with  first  item. 

10.  W  -  Probability  of  at  least  one  defect  entering 
storage. 

11.  Determine  distribution  of  number  of  defects  pres¬ 
ent  upon  entering  storage: 

W(0)  -  1  -  W 

Thus,  letting  v  -  -log  (1-W) ,  the  Poisson 
parameter  consistent  with  W(0)  “1-W,  one 
obtains 

-V  y 

w(y)  “  y/  .  y  “  0,  1,  2,  .  .  . 

12.  Determine  distribution  of  number  of  defects  occur¬ 
ring  in  storage  prior  to  first  test. 

-At 

R(x)  "  ^ X  -  0,  1,  2,  .  .  . 

where  A  -  in-storage  failure  rate 

t  “  time  to  start  of  first  test 

13.  Convolute  R  and  W  to  obtain  distribution  of  total 
defects  present  upon  entering  first  test. 

X 

B(x)  “  E  R(k)  W(x-k),  x  “  0,  1,  2,  .  .  . 
k-0 

B  is  the  distribution  of  R+W. 

lA.  D  “  Probability  defect  entering  test  will  be  de¬ 
tected. 
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15.  Determine  matrix  D(M1,  M2)  the  probability  that 
M2  of  Ml  defects  will  be  detected. 

D(M1,  M2)  -  ^“2]  Ml-0.  1.  2,..., 

M2-0,  1,  2,  ....  Ml 

using  the  standard  binomial  distribution  for 

M2  successes  out  of  Ml  trials. 

16.  X  “  Probability  of  at  least  one  defect  occurring 
during  test, 

17.  Determine  distribution  of  number  of  defects  occur¬ 
ring  during  test: 

X(0)  =  1-X 

Letting  a  »  -log  (1-X),  one  obtains 
-a  X 

X(x)  »  ^  2.  •  .  . 

18.  E  =  Probability  of  detecting  failure  occurring 
during  test. 

19.  Determine  matrix  E(M1,  M2): 

Emw2)  .  (“)  E®  (1-E)®-®.  . . 

M2“0,l,2, . . . ,Mi  similar  to  D. 

20.  Determine  distribution  of  number  of  failures  pres¬ 
ent  prior  to  test  which  go  undetected: 

N(x)  =  E  B(k)  D(k,k-x),  x  •=  0,  1,  2,  .  .  . 
k=x 

21.  Determine  distribution  of  number  of  failures 
occurring  during  test  which  go  undetected: 

N$(x)  =  Z  X(k)  E(k,k-x),  x  =  0,1,2,... 
k=x 

22.  Convolute  N  and  N$  to  obtain  distribution  of  total 
defects  which  are  present  but  undetected  at  end  of 
test: 

X 

W(x)  »  Z  N(k)  N$(x-k),  X  =  0,  1,  2,  .  .  . 
k=0 

23.  Proceed  to  next  test  using  W  from  22  as  the  dis¬ 
tribution  of  defects  present  prior  to  next  test. 
Repeat  steps  12  through  22  for  next  test. 

24.  Repeat  23  until  last  test  prior  to  call-up  is 
completed,  test  Number  Nl-1. 

25.  Repeat  steps  12  through  19  for  call-up  test. 

26.  Determine  distribution  of  number  of  failures  pres¬ 
ent  prior  to  call-up  test  which  are  detected: 

N(x)  «  Z  B(k)  D(k,x),  x  -  0,  1,  2,  .  .  . 
k-x 

27.  Determine  distribution  of  number  of  failures 
occurring  during  call-up  test  which  are  detected: 

N$(x)  -  Z  X(k)  E(k,x),  X  -  0,  1,  2.  .  .  . 

k"X 

28.  Convolute  N  and  N$  to  obtain  distribution  of  total 
defects  which  are  detected  during  call-up  test: 

W(x)  -  E  N(k)  N$(x-k),  x  -  0,  1,  2,  .  .  . 
k-0 

29.  Print  out  distribution  of  number  of  detected  fail¬ 
ures  for  item  number  one.  Also  determine  and 
print  out  average  number  of  detected  failures. 

30.  Determine  Z(y),  the  probability  of  y  days  delay 
due  to  1  em  number  one: 


Z(y)  -  E  W(k),  y  »  0,  1,  2,  ...  in  days 
keM 

where  M  «  (k:  y  <k  ,  T'  .  E'  £  y+1) 

T'  “  repair  time  for  item  for  one  detected 
defect . 

Probability  associated  with  repair  times  greater 
than  y  days  but  less  than  y+1  days  ate  grouped  as 
the  probability  of  a  y  day  delay  due  to  item  num¬ 
ber  one. 

31.  Repeat  steps  10  through  29  for  item  number  two. 

32.  Determine  Z$(y),  the  probability  of  y  days  delay 
due  to  item  two: 

Z$(y)  =  E  w(k),  y  =  0,  1,  2,  ...  in  days 
keM 

where  M  =  (K:  y  <  k  .  T'  •  E'  £  y+1) 

33.  Convolute  Z  and  Z$  to  obtain  distribution  of  the 

probability  of  y  days  delay  due  to  items  one  and 
two: 

y 

Y(y)  -  E  Z(k)  .  Z$(y-k),  y  =  0,  1,  2,  .  .  . 
k=0 

34.  Let  Z(y)  =  Y(y)  for  y  =  0,  1,  2,  .  .  . 

35.  Repeat  steps  10  through  29  and  steps  32  through 

34  for  items  three,  four . N. 

36.  Print  out  average  days  delay  for  each  item  and 
percent  of  total  each  contributes. 

37.  Print  out  final  Z(y),  y  “  0,  1,  2,  ...,  the  dis¬ 
tribution  of  days  delay  due  to  items  one  through  N. 

3.  EXAMPLE  OF  SPACECRAPT  APPLICATION 

This  section  illustrates  the  application  of  the 
analysis  to  the  storage  of  a  spacecraft  while  awaiting 
an  unscheduled  launch  call.  The  manner  in  which  input 
data  were  estimated,  the  way  cases  were  structured,  and 
the  types  of  conclusions  which  were  drawn  are  all 
described. 

Data  Requirements 

The  Inputs  to  the  model  can  be  determined  from  a 
variety  of  sources.  If  the  equipment  under  consider¬ 
ation  is  mature  (e.g.,  a  TV  set),  then  the  probability 
of  failure  could  be  determined  using  the  failure  rate 
and  the  operating  time  of  the  test.  Another  method 
would  be  the  failure  history  of  the  equipment  during 
tests  similar  to  those  to  be  conducted  during  storage 
and  reactivation.  If  the  equipment  is  stored  in  the 
unpowered  state.  References  2,  3,  and  4  provide  data 
for  determining  the  probability  of  failure  during 
storage. 

The  probability  of  detecting  falures  (test  effi¬ 
ciency)  is  a  function  of  the  parameters  tested,  the 
environment  of  the  test  (ambient,  hot,  cold)  and  the 
failure  rates  of  the  test  equipment  (probability  of  not 
detecting  a  failure  when  it  occurs).  A  method  of  deter¬ 
mining  test  eeficiency  is  to  compare,  for  each  test 
considered,  those  parameters  tested  versus  those  not 
tested.  This  results  in  a  percentage  of  the  total  para¬ 
meters  tested  and  allows  for  a  comparison  of  the  effi¬ 
ciencies  of  the  various  tests;  however,  the  environments 
and  test  equipment  must  still  be  accounted  for.  It  is 
also  possible  to  determine  the  test  efficiency  from  the 
failure  data. 

For  the  example  shown  herein,  it  was  decided  to 
'•tc  the  failure  data  collected  during  spacecraft  test¬ 
ing.  It  was  felt  that  this  single  data  source  account¬ 
ed  for  all  aspects  of  determining  the  probability  of 
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detecting  failures.  The  two  inputs  that  differed  from 
this  were  the  storage  failure  rate  and  the  repair  time. 
The  storage  failure  rate  used  was  taken  to  be  lOZ  of 
the  predicted  operating  failure  rate.  The  repair  time 
was  estimated  based  on  experience  from  troubleshooting, 
removing,  replacing,  and  retest  for  the  spacecraft 
under  consideration. 

Each  failure  report  was  reviewed  and  classified 
as  to  type  of  failure,  type  of  test,  subsystem  and 
environment  where  the  failure  could  be  detected.  The 
types  of  failures  were  as  follows: 

•  Spacecraft  Hardware  Failure  -  This  category  was 
further  subdivided  to  identify  latent  failures. 

These  were  workmanship  failures  attributed  to 
manufacturing  or  a  vendor  that  should  (or  could) 
have  been  detected  during  earlier  testing. 

•  Test  Failure  -  This  category  included  all  test 
equipment  failures,  procedure  problems,  opera¬ 
tor  error,  etc. 

•  Non-Failure  -  These  were  usually  minor  out-of¬ 
tolerance  conditions  which  did  not  result  in 
replacement  of  hardware  and  were  dlspositloned 
"use-as-is."  These  were  deleted  from  the  sample 
since  they  did  not  require  repair. 

The  types  of  testing  were  identified  because  the 
same  types  of  testing  as  accomplished  during  integration 
and  test  were  proposed  for  storage  and  reactivation. 

This  allowed  for  the  determination  of  failure  probabil¬ 
ity  and  detection  for  the  tests  involved.  Three  gener¬ 
al  areas  of  testing  were  identified:  subsystem  integra¬ 
tion,  ambient  test,  and  thermal  vacuum.  The  ambient 
testing  was  further  subdivided  into  integration  system 
testing  (1ST),  pre-thermal  vacuum,  and  post-thermal 
vacuum. 

The  subsystems  were  those  normally  identified  with 
a  spacecraft;  however,  in  some  instances  it  was  neces¬ 
sary  to  regroup  some  of  the  hardware  into  different  cat¬ 
egories  because  of  differences  in  repair  time  since  the 
program  will  only  accept  one  repair  time  per  subsystem. 
All  the  test  failures  were  grouped  into  a  subsystem 
identified  as  Test  Equipment.  This  category  also  ac¬ 
counted  for  the  possibility  that  test  equipment  could 
erroneously  indicate  the  presence  of  a  failure  when 
none  was  present.  The  "subsystems"  correspond  to  the 
"items"  described  earlier. 

The  identification  of  the  various  environments 
where  the  failure  could  be  detected  was  necessary  be¬ 
cause  some  failures  could  only  be  detected  at  thermal 
vacuum  conditions  while  others  could  only  be  detected 
at  ambient  conditions  (visual  inspection,  etc.).  For 
the  most  part,  the  failures  could  be  detected  at  either 
environment . 

Upon  completion  of  the  data  review  it  was  decided 
to  eliminate  those  falllures  occurring  during  subsystem 
integration  since  the  objective  was  to  determine  the 
failures  expected  of  a  completely  assembled  spacecraft. 
This  left  a  total  of  12  ambient/thermal  vacuum  cycles 
u;;cn  which  to  base  the  probabilities  required  by  the 
analysis  model. 

The  task  of  determining  failure  probabilities  from 
number  of  failures  was  accomplished  by  using  the  aver¬ 
age  number  of  failures  detected  and  the  Poisson  distri¬ 
bution.  The  method  is  illustrated  for  a  typical  sub¬ 
system  using  the  12  ambient /thermal  vacuum  tests  noted 
above. 

a.  Total  number  of  failures  detected  -  28 

28 

b.  Average  failures  per  test  (•^)  -  2.33 

c.  Probability  of  failure  occurring: 


P  =  0.903 

Each  subsystem  was  handled  in  the  same  manner.  If  no 
failure  occurred  in  the  subsystem,  one  failure  was  con¬ 
servatively  assumed.  The  probability  of  a  defect  exist¬ 
ing  when  entering  storage  was  determined  in  the  same 
manner  as  above  except  the  latent  failures  identified 
earlier  were  used. 

The  probability  of  detecting  failures  was  determin¬ 
ed  from  the  latent  failures  and  the  environment  where 
detected.  As  an  example,  one  subsystem  showed  10  latent 
failures  which  could  be  detected  at  either  ambient  or 
thensal  vacuum.  Of  these,  eight  were  detected  at  ambi¬ 
ent  and  two  at  thermal  vacuum;  therefore,  the  probabil¬ 
ity  of  detecting  latent  failures  at  ambient  was  80%  and 
the  probability  for  thermal  vacuum  was  20%  better  or 
96%.  The  probability  of  detecting  a  failure  occurring 
during  test  was  assumed  to  be  the  same. 

All  subsystems  did  not  display  the  above  trend 
since  latent  failures  were  not  prevalent  and/or  total 
failures  were  small  and  detected  at  both  environments. 

It  was  assumed  the  detection  capabilities  would  be  the 
same  regardless  of  the  type  of  testing  and  would  be  at 
least  as  efficient  as  the  most  effective  test  (.96). 

Results 

A  study  was  initiated  with  the  purpose  of  evalua¬ 
ting  an  existing  test  plan  for  the  long-term  storage  of 
a  spacecraft  which  must  be  launched  within  75  to  140 
days  after  an  unscheduled  call-up.  The  difference  in 
launch  schedule  resulted  from  the  type  of  reactivation 
testing  conducted  prior  to  shipment  (ambient  versus  am¬ 
bient  plus  environmental  testing) .  The  original  purpose 
of  the  study  was  to  determine  whether  or  not  the  recom¬ 
mended  shipment  dates  could  be  met  (30  days  prior  to 
launch) .  The  analysis  model  developed  for  this  study 
was  directed  at  the  number  of  days  delay  due  to  failures 
(and  their  repair  times)  in  the  system  and  had  to  be 
compared  to  the  contingency  allowed  for  these  failures. 

The  test  plan  consisted  of  three  different  types  of 
reactivation  testing  based  on  the  time  since  the  last 
thermal  vacuum  test  (T/V).  The  least  of  the  tests  was 
an  integrated  system  test  (1ST),  the  second  was  a  very 
detailed  ambient  test  and  the  final  test  was  the  ambient 
test  plus  a  very  difficult  thermal  vacuum  (T/V)  test.  In 
addition  the  test  plan  called  for  the  spacecraft  to  be 
stored  without  power  applied,  with  the  Propulsion  Sub¬ 
system  pressurized,  a  controlled  humidity  and  a  nitrogen 
environment . 

In-storage  testing  was  to  consist  of  a  quarterly 
electrical  test  which  was  basically  an  "allveness  test." 
Additionally  a  detailed  ambient  test,  a  T/V  test  and  a 
post  T/V  ambient  test  were  to  be  conducted  at  nine  month 
intervals. 

The  analysis  model  was  exercised  for  a  variety  of 
conditions  to  arrive  at  conclusions  and  recommendations 
for  the  test  program  under  consideration.  Table  3  is  a 
sample  of  the  cases  conducted  upon  which  the  final  con¬ 
clusions  and  recommendations  resulting  from  the  study 
were  based. 

The  first  three  cases  were  a  variation  in  the 
launch  Cull  to  exercise  each  of  the  three  reactivation 
test  schedules  contained  in  the  test  plan.  Case  Num¬ 
ber  1  shows  the  minimum  reactivation  testing;  based  on 
the  failures  and  days  delay  it  was  considered  to  be  a 
useless  test  and  was  eliminated  from  further  consider¬ 
ation. 


Knowing  that  the  In-storage  test  was  basically  an 
"aliveness  test,"  It  was  decided  to  study  elimination 
of  these  tests  to  determine  their  effect  on  the  overall 
program.  Case  4  of  Table  3  shows  that  they  have  no 
effect  on  either  the  days  delay  or  the  number  of  fail¬ 
ures  detected.  As  a  result,  these  tests  were  also 
eliminated  from  further  cosideratlon. 


Table  3.  Sample  of  Storage  Study  Considerations 


Case 

Number 

Launch 

Call 

(Mo.) 

Tests 
During 
Storage  (1) 

Reacti¬ 

vation 

Testing 

Average 

Failures 

Detected 

Average 

Days 

Oelav 

1 

12 

1,1,2 

1ST 

3.2 

9.3 

2 

18 

1,1.2, 

1,1 

T/V 

13.1 

28.8 

3 

24 

1.1.2, 

1,1.2 

Ambient 

7.7 

18.7 

4 

24 

2,2 

Ambient 

7.7 

18.7 

5 

24 

None 

Ambient 

9.9 

22.8 

6 

24 

None 

T/V 

14.1 

30.7 

7 

24 

None 

T/V  (2) 

4.2 

8.6 

8 

24 

None 

Ambient 

(3) 

13.1 

30.6 

9 

24 

None 

T/V  (3) 

15.9 

38.4 

1C 

24 

2 

T/V 

11.9 

26.4 

11 

24 

2,2 

T/V 

11.3 

25.2 

12 

24 

2,2,2 

T/V 

11.3 

25.1 

13 

24 

2 

T/V  (3) 

13.4 

29.9 

14 

24 

2,2 

T/V  (3) 

12.7 

28.5 

15 

24 

2,2,2 

T/V  (3) 

12.7 

28.5 

16 

24 

None 

T/V 

14.1 

80.3 

(1)  Test  Number  1  is  an  in-storage  electrical 
(aliveness)  test.  Test  Number  2  is  an 
ambient  plus  a  T/V  test. 

(2)  Indicates  that  no  failures  occur  during 
reactivation  testing. 

(3)  Indicates  perfect  detection  during  reacti¬ 
vation  testing. 

The  next  step  was  to  evaluate  the  effect  of  no 
testing  during  storage.  Cases  5  and  6  study  these  ef¬ 
fects.  Both  the  failures  and  the  delay  were  increased 
over  Cases  2  and  3;  however,  these  increases  were  not 
considered  significant.  The  test  plan  contained  17 
days  contingency  for  the  ambient  test  and  22  days  for 
the  T/V  test.  Since  the  test  plan  was  based  on  a  40- 
hour  single  shift  work  week,  the  delays  estimated  by 
the  analysis  model  were  not  considered  excessive. 


dividing  the  failures  in  Cases  5  and  6  by  those  in 
Cases  8  and  9  it  is  seen  that  the  T/V  test  is  the  most 
efficient  even  though  more  failures  are  Introduced, 
(ambient  is  76Z  effective  while  T/V  is  89Z  effective). 

As  a  result,  only  T/V  testing  was  considered  in  the 
remainder  of  the  cases. 

Cases  10  through  12  of  the  table  represent  an 
attempt  to  determine  whether  or  not  more  intensive 
testing  during  the  storage  period  would  eliminate  •'he 
failures  remaining  in  the  spacecraft.  These  thre.^ 
cases  when  compared  to  Case  6 ,  indxc..  ted  that  some  of 
the  failures  could  be  eliminated  by  interim  testing; 
however.  Cases  13  through  15  Indicate  that  some  fail¬ 
ures  are  left  in  the  system  and  cannot  be  eliminated 
(e.g..  Cases  12  and  15  -  12.7-11.3=1.4).  Since  this 
matched  our  launch  experience,  the  study  was  terminated 
at  this  point.  It  should  also  be  pointed  out  that  the 
failures  used  in  the  study  were  reviewed  to  determine 
their  effect  on  orbit.  For  the  most  part,  these  fail¬ 
ures  were  considered  minor;  this  also  coincided  with 
past  experience. 

Up  to  this  point  in  time,  the  spares  complement 
was  considered  \mllmlted;  e.g.,  it  was  assumed  that  an 
on-going  program  was  following  or  that  several  vehicles 
were  in  storage  allowing  for  units  to  be  removed  from 
other  spacecraft.  During  the  study,  units  began  failing 
which  had  not  failed  previously  and  for  which  no  spares 
were  available.  This  resulted  in  a  reevaluatlon  of  the 
spares  complement  and  their  recycle  time  through  manu¬ 
facturing,  test,  and  return  to  the  spacecraft.  Case 
Number  16  is  a  sample  of  the  days  delay  associated  with 
this  type  of  situation  and  represents  an  unacceptable 
condition. 

Based  upon  the  study  results  represented  by  Table 
3,  the  conclusion  was  to  place  the  spacecraft  in  stor¬ 
age,  conduct  no  tests  until  the  launch  call  is  received 
and  then  to  conduct  a  T/V  test.  Additionally,  it  was 
recommended  that  a  complete  complement  of  spares  be 
provided.  Management  took  the  above  results  and,  con¬ 
sidering  cost,  manpower  requirements,  etc.,  arrived  at 
the  conclusion  that  interim  T/V  tests  should  be  conduc¬ 
ted  at  one  year  intervals  for  crew  training  purposes. 
They  also  recommended  that  the  spares  complement  be 
Increased  over  the  present  level. 

Our  customer  has  not,  to  date,  directed  us  to  re¬ 
vise  our  test  program  per  ti.o  recommendations.  He  has, 
however.  Issued  a  contract  to  complete  our  spares  com¬ 
plement. 

4.  OTHER  APPLICATIONS 


At  this  point  a  question  was  raised  concerning 
the  source  of  the  failures;  e.g.,  how  many  were  being 
Introduced  by  the  testing  and  how  many  were  present  at 
the  beginning  of  the  test.  Additionally,  concern  was 
shown  over  the  efficiency  of  the  tests  and  how  many 
failures  would  still  be  remaining  in  the  system  after 
the  reactivation  testing,  i.e.,  at  launch.  Cases 
Number  7,  8  and  9  are  examples  of  runs  conducted  to 
answer  the  above  questions.  By  changing  the  working 
copy  of  the  program  at  the  terminal.  Case  Number  7  was 
accomplished  allowing  no  failures  to  occur  during  re¬ 
activation  testing;  comparing  Cases  6  and  7  indicates 
that  at  least  4.2  failures  were  present  at  the  start 
test  and  9.9  were  caused  by  the  test  (14.1-4.2=9.9). 
The  failures  introduced  by  the  tests  were  further  iden¬ 
tified  as  test  or  spacecraft  failures.  Some  spacecraft 
failure  were  also  identified  as  incipient  failures 
accelerated  by  the  T/V  tests.  Cases  Number  8  and  9 
"ere  created  by  changing  the  program  to  allow  perfect 
detection  during  reactivation  testing.  Comparing  them 
"ith  Cases  5  and  6  shows  that  failures  will  be  unde¬ 
tected  and  remain  in  the  system  at  launch.  Also  by 


Other  potential  applications  of  the  analysis  tool 
described  in  this  paper  have  been  alluded  to,  things 
such  as  stored  weapon  system  held  in  readiness  in  case 
of  an  emergency;  piece  parts  placed  in  electronic  stores 
prior  to  assembly;  electronic  boxes  stored  prior  to  in¬ 
tegration  into  a  system;  TV  sets  and  hi-fi  equipment 
stored  in  warehouses  before  shipment  to  showrooms;  used 
cars  sitting  on  a  lot  waiting  for  a  new  owner  to  arrive. 
The  list  of  such  applications  is  potentially  a  very  long 
one.  This  section  examines  a  few  such  situations  in 
more  detail,  pointing  out  some  of  the  Important  ques¬ 
tions  which  could  be  stud*ud  by  use  of  such  analyses. 

Two  less  obvious  examples  relating  to  psychology  and 
baseball  are  touched  upon. 

Missiles  in  Silos 

The  equipment  constituting  the  U.S.  retaliatory 
strike  capability  is  a  classic  example  of  stored  equip¬ 
ment  subject  to  a  random  or  non-predetermined  call-up 
use.  The  problems  of  what  storage  conditions,  what 
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type  of  checkout  procedures  to  apply  and  how  often> 
have  received  extensive  study  over  a  long  period  of 
time.  Analyses  of  the  type  discussed  in  the  preceding 
sections  should  have  played  a  key  role  in  the  reaching 
of  decisions  on  these  matters.  Indeed,  the  need  for 
nearly  instantaneous  response  to  the  call-up  has  led  to 
very  frequent  checkout  routines;  in  many  cases  critical 
items  are  turned  on  continuously  and  monitored,  an  in¬ 
stance  of  infinitely  frequent  testing  as  a  means  of 
dealing  with  a  near  zero-time  reaction  goal. 


An  analysis  using  a  framework  similar  to  that 
found  in  the  storage  model  would  doubtless  identify  a 
maximum  number  of  days  off  which  each  pitcher  can  typi¬ 
cally  tolerate.  Periodic  games  pitched  entirely  by 
little  used  relief  pitchers  would  be  one  way  to  keep 
his  entire  staff  in  shape  to  be  called  upon  when  need¬ 
ed.  This  approach  is  also  analogous  to  per idle  cali¬ 
bration  of  electronic  test  equipment.  No  pitcher 
should  be  allowed  to  exceed  his  recommended  calibra¬ 
tion  periods. 


Spare  Electronic  Boxes 
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In  many  cases  electronic  boxes  are  available  for 
integration  into  a  system  long  before  the  system  build¬ 
up  process  is  ready  for  them.  The  boxes  are  then  stored 
until  they  are  needed.  In  a  normal  assembly  situation 
the  questions  of  test  frequency  in  storage  are  not  acute 
since  the  time  of  use  is  hopefully  known  well  in  advance 
The  situation  is  more  critical  in  the  case  of  a  spare 
box  required  only  in  the  event  of  a  failure  of  a  primary 
unit  already  integrated  into  Che  system.  Such  a  spare 
box  is  Indeed  subject  to  a  random  demand:  its  rapid 
availability  to  the  system  is  more  critical  than  normal 
since  the  spare  is  only  required  when  some  other  anomaly 
has  already  occurred  and  schedules  are  very  likely  in 
jeopardy.  Finding  that  the  spare  has  also  failed  when 
it  is  taken  from  storage  would  certainly  insure  (i)  sig¬ 
nificant  delays;  (li)  Imposition  of  penalties  for  tardy 
delivery  if  such  provision  were  in  the  contract;  and 
(ill)  a  damage  to  the  company  reputation.  Stored  spares 
could  be  treated  exactly  as  stored  spacecraft  were  in 
the  examples  above. 

Spare  Tire  in  a  Passenger  Car 

The  previous  example  hits  particularly  close  to 
home  if  you  have  ever  had  a  flat  tire  only  to  find  that 
your  spare  is  also  flat  when  it  is  pulled  from  its  hid¬ 
ing  place.  How  often  do  you  check  the  air  pressure  in 
your  spare? 

Learning  Theory  in  Psychology 

Knowledge  is  stored  in  the  brain  and  called  upon 
in  special  situations.  The  longer  it  has  been  since 
some  class  of  knowledge  has  been  called  upon,  the  less 
is  ones  assurance  that  it  will  he  accessible  when  need¬ 
ed.  Reviews  of  previously  learned  information  corre¬ 
spond  to  the  storage  tests  of  our  model;  forgotten  data 
corresponds  to  defects  uncovered  by  storage  tests;  re¬ 
learning  forgotten  data  is  the  repair  action  adopted  to 
remedy  the  failure.  An  interesting  learning  theory 
study  could  be  based  upon  this  storage  model,  investi¬ 
gating  the  optlmxim  review  frequency  and  intensity  for 
various  types  of  information,  so  that  an  adequate  recall 
would  occur  when  the  data  were  needed  at  some  unexpected 
time. 

Relief  Pitcher  in  Baseball 


The  relief  pitchers  lolling  in  the  bullpen  are 
actually  in  storage  awaiting  an  unscheduled  demand  for 
their  services.  The  more  days  which  go  by  without  hts 
pitching,  the  less  becomes  the  manager's  confidence 
that  the  pitcher  will  "have  it"  when  called  up  with  the 
bases  loaded.  The  lower  the  manager's  confidence,  the 
less  frequently  does  he  call  upon  the  pitcher.  This 
cycle  leads  to  the  often  observed  dependence  of  a  man¬ 
ager  upon  one  or  two  relief  pitchers  whom  he  tests  of¬ 
ten  enough  to  have  confidence  in.  They  each  appear  in 
roughly  half  of  the  games  in  a  season  and  typically 
burn  themselves  out  in  two  or  three  seasons.  A  manager 
wishing  to  profit  from  aerospace  technology  would  eval¬ 
uate  existing  data  on  times-between  appearances  and  its 
correlation  with  performance  for  each  of  his  relief 
pitchers. 
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Figure  1.  Flow  of  Storage  Events 


Figure  2.  CoopuCer  Program  Flow  Diagram 
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